Date: Fri, 4 Mar 94 04:30:19 PST From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #58 To: Ham-Digital Ham-Digital Digest Fri, 4 Mar 94 Volume 94 : Issue 58 Today's Topics: Errors in TNC2 firmware??? IM_Mac1.0b27y.sea.hqx.text Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 28 Feb 94 06:25:08 GMT From: nprdc!ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!tern.csulb.edu!usenet@network.ucsd.edu Subject: Errors in TNC2 firmware??? To: ham-digital@ucsd.edu I have recently been experimenting with TNC2 clones and had run across two peculiar "bugs" in the firmware of an MFJ 1278, and a tiny TNC2. The first problem relates to when the TNC2 sends to the computer the "Change incoming stream" command ("|B" to switch to stream B, for example). It seems that when in command mode, the TNC set the output stream to be equal to the input stream whenever it sends the "cmd:" prompt (if, of course. the output stream was set to something else previously). So it you are in command mode in stream A, and send a "|b" to set the input stream to B, and press Enter, the tnc will respond with "|Bcmd:" to tell that the output stream should now ALSO be set to stream B. The problem is this: The stream switch is sent JUST before sending the cmd: prompt. So if you are on stream A in command mode, and type "|bcst" to set the input to stream B and get the status of all streams, the tnc will send the results, THEN the |B, then the new cmd: prompt. SO, the output of the cst request made on stream B will be sent to stream A. In fact, the results will show that the input stream is B, while the output stream is A! Of course, if you type another "cst", the results will be sent to the proper stream, because it has already been corrected. Do all TNC2's exhibit this feature? The second problem is more major. I seems that when I am connected on two streams, and send text out on the first stream, and then switch to the second and do nothing, all output from the tnc is halted. For example, if I am connected on stream A and B to two bbs's, and I am currently on stream A, and I send "l|B" to list all files on the first bbs and then switch my input to the second bbs, the tnc will halt all output back to me. The results of the list command will come back to the tnc, and the tnc will receive them all internally, but will not send them to the computer....UNTIL I sent something to the tnc first. (Usually I send "^ck" to enter and then leave command mode. This will then allow all buffered data to be sent to me. However, it you do not send anything to the tnc, it will send nothing to you. I have found these problems by using paKet 5.1. PaKet creates a different window for each of the tnc's streams, and pressing a shifted arrow key allows you to switch between the streams. When you do this, paKet sends a "|" and the stream identifier. Therefore, it is very easy to switch to another stream to view incoming data, without wanting to send anything, thus causing the second problem. And having entering a command in one window and having the output return in another window (the first problem) was also easily spotted. I have reproduced these problems using a simple terminal, so they are not errors with paKet. One other note. I have also played with some Kantronics Tnc. They do not appear to have the lockup problem, but have an even worse version of the first bug. The incoming stream sent from the Kan TNC's is only changed when data comes in from over the air, not from commands. So if I am on stream A, and switch to stream B, SEND a , (this would fix the TNC2 problem), and start sending commands, the tnc never send me the stream switch command, so all the feedback from my commands always goes to stream A, (or whatever the last stream to receive over the air was). This is very frustrating when using paKet! Anyone have any comments on any of this? Has anyone else experienced this? Any ideas for solutions? -- Byon Garrabrant KD6BCH byon@csulb.edu ------------------------------ Date: 4 Mar 94 10:25:24 GMT From: news-mail-gateway@ucsd.edu Subject: IM_Mac1.0b27y.sea.hqx.text To: ham-digital@ucsd.edu =20 Release Notes - IM/Mac 1.0=A727y - The numbers in the option-about dialog are now correctly formatted = for all languages. - Beachball cursor stops spinning immediately after finishing updatin= g mail file when quitting. - Beachball cursor stops spinning when a system error occurs. - When a system error occurs, the dialog that shows has a 'MacsBug' b= utton when MacsBug is running. This will create a file called 'crash_log' whic= h you need to send me. - Files with filetype 'ZSYS' and creator 'MACS' (e.g., 'VM Storage') = can no longer be send. They're treated as invisible files like the Finder = does. - When selecting a file to send, the text inside the outlined button = was 'Send' instead of 'Open' if the target was an alias to a folder. - When the last item (Record) in the "Edit 'bm.rc'=C9" dialog contain= ed only a filename, a system error occured. The syntax for that line is as fo= llows: [[[::]:]]. Square brackets enclose optional ite= ms. Examples: :My Hard Disk:My TCP/IP Folder:spool:Archive:Sent Mail spool:archive:sent mail archive - Finding out if MacsBug is installed via Gestalt doesn't work. Used = another method. - Sending a file that needs to be BinHex encoded will have its name t= runcated to 27 characters to make room for the '.HQX' suffix in the subject tit= le. The original file name will reappear after the BinHex decoding takes pl= ace at the receiver's end. - Deleted mail icon was 1 pixel too high. - Does stuff/unstuff of files on system 7 Macintoshes that have 'Stuf= fIt Engine=AA' (version 3.0 and higher) in the Extensions folder. Files= that were compressed/made with StuffIt, Compact Pro, AppleLink, DiskDoubler o= r UpdateMaker won't stuff twice. - Beachball cursor kept spinning when a system error occured during B= inHex encoding. - On popular demand: AX25 mail: on1xk@on6ar.#an.bel.eu AMPRnet: ivo@on1xk [44.144.8.5] Internet: on1xk@gg.tno.nl AppleLink: vanursel.ivo Monday, February 28, 1994 - 18:48:54 UTC Best 73's, es cuagn de Ivo, ON1XK @ ON6AR.#AN.BEL.EU [44.144.8.5] Wednesday, March 02, 1994 - 19:55:15 +0000 UTC PS (by PA2AGA) This version obsoletes all versions of info-mac/comm/radio-immac in t= he Sumex-Aim archives. The new IM/Mac has (hopefully) been uploaded to ftp.std.com, to the directory pub/hamradio/incoming, and to ucsd.edu, to the directory /hamradio/packet/tcpip/incoming. If it's not there (anymore), then look at /hamradio/packet/tcpip/mac. ------------------------------ End of Ham-Digital Digest V94 #58 ******************************